home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Libris Britannia 4
/
science library(b).zip
/
science library(b)
/
PROGRAMM
/
CC_C
/
H001A.ZIP
/
GPPREAD.ME
< prev
next >
Wrap
Text File
|
1991-08-16
|
25KB
|
594 lines
Note: The DJGPP.ZIP has been repackaged into four smaller ZIP files in
order to avoid problems in merging pieces together to reconstruct the
large 2 megabyte ZIP originally released by the author. These files
are available in this archive as DJGPP1.ZIP, DJGPP2.ZIP, DJGPP3.ZIP,
and DJGPP4.ZIP.
Signed: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Maintainer of the SIMTEL20 MS-DOS archives
---
This is the README file for DJ's GCC port to DOS.
Contents:
* Overview
* What's available
* How to install
* Common questions
* Deviations and Caveats
* Copyright information
Disclaimer: This software is distributed WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Overview:
This package contains a 32-bit 80386 DOS extender with symbolic
debugger, a C/C++ compiler with utilities, development libraries, and
source code. It generates full 32-bit programs and supports full
virtual memory with paging to disk.
Requirements:
A 80386-based IBM compatible PC or PS/2 is required. The 80387 emulator
currently does not emulate trancendental functions (exp, sin, etc).
Approximately 4-5Mb of hard drive space is required. 640K RAM is
required.
Supported Wares:
* Up to 128M of extended (not expanded) memory
* Up to 128M of disk space used for swapping
* SuperVGA 256-color mode up to 1024x768
* 80387
* XMS & VDISK memory allocation strategies
Unsupported:
* V86 programs, like QEMM, 386MAX, DesqView, Windows/386, etc.
File location:
host: grape.ecs.clarkson.edu
login: ftp
password: send your e-mail address
directory: ~ftp/pub/msdos/djgcc
NOTE: In accordance with FSF CopyLeft, you are not allowed to upload
this program to a distribution site unless that site also makes the FSF
sources for these programs available. Please read the file COPYING for
more details. FSF sources are available on prep.ai.mit.edu, and on
either grape.ecs.clarkson.edu or sun.soe.clarkson.edu
NOTE: If your application links in object modules that were written
by FSF, your application counts as a "derived work" and must obey
the provisions of the FSF Copyrights. See the file COPYING for
details. Specifically, the C++ classes in libc.a and obstacks are
FSF works that are covered by the GNU GPL. The mere act of compiling
does not affect the copyright status of your program.
File formats:
.ZIP format - djgpp.zip - one 2.2M file, contains everything.
split .ZIP - djgppzip.000 through djgppzip.065 (or so), each
32K. Use the merge program to merge them into
djgpp.zip ("merge djgppzip djgpp.zip").
other - readme, merge.c/.exe, split.c/.exe are separately available
Directories:
bin all binaries (cpp, cc1, extender, etc)
lib all libraries (crt0.*, libc.a, libgr.a, libpc.a)
include all include files (arc'd tar file)
docs all documents (including this one)
go32 sources for the extender
drivers various SuperVGA drivers
libsrc sources for the libraries (arc'd tar file)
diffs diffs from FSF distributions to dos-compilable
utils sources for the utilities
samples sample C++ sources using graphics & mouse
emu387 80387 emulator for non-80387 systems (currently TEST version)
bin:
bison.exe lalr(1) parser
flex.exe lexical parser
cpp.exe C and C++ preprocessor
cc1.exe C compiler
cc1plus.exe C++ compiler
as.exe 80386/80387 assembler
ld.exe a.out (BSD) format linker
ar.exe archive utility
nm.exe name list utility
size.exe a.out section size utility
strip.exe symbol stripper
objdump.exe display info from .o file
gcc.exe compilation coordinator
go32.exe basic 32-bit DOS extender
debug32.exe 32-bit DOS extender with symbolic debugger
stub.exe stub to prepend on aout files to make .exe files
aout2exe.bat turns aout file to .exe by prepending stub.exe
diff.exe creates diffs, including context diffs
patch.exe patches source from diffs, including context diffs
djtarx.exe tar extractor for FSF tarfiles if you don't have a tar
utod.exe convert Unix text files to DOS text files
dtou.exe convert DOS text files to Unix text files
split.exe split big binaries into many little binaries
merge.exe merge many little binaries back into one big binary
lib:
libc.a all standard routines (BSD style), and C++ methods & support
libm.a math routines
libgr.a graphics routines and mouse support
libpc.a routines for PC support (in/out, getkey, kbhit, screen utils)
crt0.s C runtime source
crt0.o C runtime object
bison.simple bison support
bison.hairy bison support
flex.skel flex support file
libflex.a flex support library
include:
Most BSD-style and SYSV-style include files. These mostly came from
the G++ sources.
sys/*.h MS-DOS specific
graphics.h for libgr.a
pc.h for libpc.a
mouse.h for mouse routines in libgr.a
docs:
readme this document
copying GNU General Public License
copying.dj Copyright information for items (C) DJ Delorie
debug32.doc instructions for the symbolic debugger
internal.doc information about how the extender works
libc.a differences and enhancements
libm.a list of implemented functions
libpc.a documentation
libgr.a documentation
go32:
sources for the extender. Requires Turbo C and Turbo Assembler
drivers:
VGA and SuperVGA drivers - source and binary. Use the GO32 environment
variable to select and configure one of these according to the VGA card
you have.
libsrc:
Sources for the libraries. These are compiled with gcc. The makefile
is set up for NDMAKE. The source files came from three sources:
(1) Me. Mostly the system call routines, and some string routines.
All of libpc.a, libgr.a, libm.a .
(2) FSF. These are the GCC support routines, C++ support, and
other routines that came with gcc (malloc, obstack, alloca, etc)
(3) BSD. These are mostly the stdio and stdlib routines, and
the rest of the string routines. BSD requires that I mention
that their sources are copyright BSD and that I have modified
some to comply with the include files provided by FSF. These
sources are the "freed files" everyone keeps talking about.
diffs:
Context diffs from the original FSF sources to the GNUDOS sources. See
the README and VERSIONS files in that directory for more info.
utils:
Sources for djtarx, utod, dtou, split, and merge.
samples:
Various samples showing how to use the mouse, graphics, C++, setjmp(),
etc.
emu387:
80387 emulator and source code. Currently, this is a TEST version, as
I'm not done with it yet. Trig, log, exp functions are missing, for
starters. I don't expect this to work perfectly, but should cover
most normal floating point math. To use, add "emu /djgcc/emu387/emu387"
to the GO32 environment variable. (ie: set GO32=emu /djgcc/emu387/emu387)
INSTALLING:
To install, you must do the following:
* Create a directory to install in, like c:\djgpp.
* Create a "temp" directory, like c:\tmp.
* Un-zip djgpp.zip in that directory.
C:\DJGPP> pkunzip -d djgpp.zip
* Add the following lines to C:\AUTOEXEC.BAT:
set gccbin=c:/djgpp/bin
set gccinc=c:/djgpp/include
set gcclib=c:/djgpp/lib
set gcctmp=c:/tmp (TMP and TEMP are checked if this isn't set)
set go32=ansi driver c:/djgpp/drivers/tseng4k.grd gw 1024 gh 768
^^^ or whatever driver works with your VGA (optional)
set bison_simple=c:/djgpp/lib/bison.simple
set bison_hairy=c:/djgpp/lib/bison.hairy
set flex_skeleton=c:/djgpp/lib/flex.skeleton
Remember that unless you manually type these at the command line,
they won't take effect until you reboot. Don't include the "ansi"
keyword in the "go32" variable if you don't have an ANSI.SYS driver
or equivalent.
* Add your binaries directory to your PATH in C:\AUTOEXEC.BAT
SET PATH= . . . ;C:\DJGPP\BIN
That's it! G++ is now installed on your system.
The GO32 environment variable:
This variable controls the options available in go32 or debug32. The
syntax of this variable is:
SET GO32=[parm [value]] [parm [value]] . . .
Parameters:
ansi Use ANSI commands to control the color in debug32
mono Use the Monochrome monitor for debugging - useful when
debugging graphics applications
emu [path] Use the specified file as the 80387 emulator
driver [path] Use the specified file as the graphics driver
gw [width] Default graphics width
gh [height] Default graphics height
tw [width] Default text width
th [height] Default text height
These parameters may occur in any order.
Examples:
C:\> set go32=mono driver c:\djgpp\drivers\tseng4k.grd gw 1024 gh 768 tw 132 th 43
C:\> set go32=ansi
C:\> set go32=driver c:\djgpp\drivers\tseng4k.grd ansi
Common Questions:
Q: When I run "gcc e:\proj\prog.c" it says "undefined escape sequence \p"?
A: Gcc is a *unix* compiler - you must use *unix* slashes (e:/proj/prog.c).
Environment variables (like GCCINC) may, however, use either, as they
are converted.
Q: I type "GCC PROG.C" and ld complains about PROG.C not being an object.
Q: I type "gcc prog.cxx" to compile a C++ program, and ld complains.
A: Gcc is *not* case insensitive like DOS is, and it uses the file's
extension to determine how to compile a file. Valid extensions are:
.cc = C++ source (passed through cpp)
.c = C source that must be passed through cpp first
.i = raw C source (no cpp pass)
.S = assembler that must be passed through cpp first
.s = raw assembler source (no cpp pass)
any other file is passed to the linker
Q: I compile my program, but can't run the output file.
A: DOS doesn't know how to run unix-style a.out files. That's what the
extender is for. To run an a.out file called myprog, type
"go32 myprog . . ."
Q: Gcc doesn't recognize // as a comment in my C programs.
A: That's because // isn't a comment in C. If you want to compile C++,
then write C++ programs. Gcc is really two compilers in one, not
one compiler that compiles both C and C++. That's why you get
cc1 and cc1plus.
Q: I'm reading in data files, but the data gets corrupted.
A: The default file type is DOS text, even for read() and write(). You must
tell the system that a file is binary through the "b" flag in fopen(),
or O_BINARY in open().
Q: I get "fatal signal 2" when I run gcc.
A: When gcc reports a "signal", it really means that an error occurred
trying to run the given program. The "signal" number is the DOS error
code, and 2 means "file not found". Check the GCCBIN environment
variable and make sure it points to the directory with cpp.exe,
cc1.exe, etc.
Q: The binaries I get with the distribution are .exe files, but gcc creates
a.out files. I rename the a.out's to .EXE's, but they still don't work.
A: To get an .EXE from an a.out, you must *prepend* either go32.exe,
debug32.exe, or stub.exe to the file:
copy /b stub.exe+myprog myprog.exe
Q: What is stub.exe?
A: Stub.exe simply calles go32.exe, and passes it information it needs to
run the a.out file attached to it. Stub is much smaller than go32, so
less disk space is used. Also, if you change go32, you don't have to
change stub, and all the stub-ized programs will use the new go32
automatically.
Q: I want to change cc1. How do I do this?
A: First, get the GNU sources from FSF. They're usually available at
prep.ai.mit.edu in /u/emacs, if not elsewhere. Use djtarx to un-tar
them, as djtarx knows how to handle unix file names that aren't valid
DOS file names. Look in the "diffs" sources to see what to change the
names to when they conflict. Next, apply the "diffs" over the
GNU sources (making sure you have the right version of GNU - see the
versions file). For the gcc-1.39 sources, you must run utod (or some
other unix-to-dos converter) to compile gcc.exe, then run config-d.bat,
then run makeall.bat. For gpp-1.39, copy the g++ sources over the
completed gcc sources, apply the gpp diffs, then run makeall.bat (gpp's
now). For all other programs, just run make. Note that the makefiles
are tuned for ndmake, since it knows how to make response files.
Q: I don't have an 80387. How do I compile floating point programs?
A: Add "emu c:\djgpp\emu387\emu387" to the GO32 environment variable
(see go32 section above). This tells go32 to use the given file
as an 80387 emulator. This emulator does not support trancendental
functions like exp or sin yet, but it works well enough for compiles
and standard +-*/ functions, including sqrt(). If you don't load
this emulator, and you try to run floating point without a 387,
you will get an error.
Q: I installed an 80387 emulator in my AUTOEXEC, but it still doesn't
work. Why?
A: The CPU is running in *protected* mode, not real mode, and the information
needed to emulate the 80387 is different. Not to mention that the
exceptions never get to the real-mode handler. You must use the emu387
emulator, which is designed for go32.
Q: I can't run a.out programs under {QEMM,386MAX,Windows}.
A: Nope, you can't. These applications put the CPU into V86 mode, not
real mode, so go32 can't manage the real-protected interface
properly. Go32 literally *takes over* the computer in order to
properly service the application it is running.
Q: Can I run this on my 286? It has protected mode also...
A: True, but the 286 isn't a 32-bit processor. A 386 really is required.
Q: Can I use gcc on my 512K machine?
A: Yes, but the disk better have at least 4Mb of free space for paging.
Go32 will use all available extended memory (up to 128M) and up to
128M of disk space, for a grand total of 256M of virtual memory for
your application. Try a malloc(50*1024*1024) some day.
Q: Why do my compiles are running VERY SLOW, even though I use a ramdisk
for swap and a disk cache?
A: Gcc requires at least 1Mb of virtual memory to run, usually close to 1.5M.
If there isn't this much real memory available, it starts paging to disk.
It's good to leave about 1M of extended (not expanded) memory available
for go32 to run programs with. When it needs to page a lot, you spend
most of your time paging and little time actually running.
Q: How much memory is available when I use the system() call?
A: Everything but what go32 is loaded with. The program is completely
paged out to memory (including the page tables themselves) before
the second program is executed.
Deviations and Caveats:
GCC/G++ deviates from the U**x version in a number of ways, mostly to
accomodate deficiencies in the MS-DOS environment, and my own laziness.
* An 80387 is required to do floating point. An emulator is provided,
but it does not support all the 80387 functions (it does +-*/ sqrt).
cc1 and cc1plus shouldn't use the 387 unless compiling floating point
code. The environment variable "387" can override the auto-detection
routine:
SET 387=YES to force 387 handlers to be enabled
SET 387=NO to force 387 accesses to fault
SET 387=QUERY to get a message showing the results of the auto-detection
If no 80387 is present and the program attempts to use it, a message
indicating where the instruction is will be displayed. To use the
387 emulator, add "emu c:\djgpp\emu387\emu387" to the GO32 environment
variable
* The VDISK method of allocating extended memory is supported. The
INT 15h method is also. When the extender runs out of conventional and
extended memory, it uses a paging file named $(GCCTMP)/pageXXXX.386, where
XXXX is an unspecified hex value. This file is normally removed on exit.
* Up to 128 MB of physical memory and 128 MB of disk swap space are allowed.
A 512K machine is sufficient, but very slow due to paging.
* The utilies support the MS-DOS standard response file method for giving
more than 128 bytes of command line. Example: "gcc -o foo @foo.lnk" where
foo.lnk contains a list of .o files.
* Since MS-DOS does not distinguish case in file names, some .h files
used for C++ have had underscores prepended to them to avoid conflict
(ie: String.h conflicts with string.h, so it became _String.h).
* When using ar to create archives, be warned that the ar version
supplied cannot update an archive that's been sequenced (ar s foo.a),
and cannot sequence a file that's been sequenced. Also, ld cannot
use an archive that's not sequenced. The following method is suggested:
ar rv mylib.a $(OBJS)
cp mylib.a mylib2.a
ar rvs mylib2.a
(and then link with mylib2.a)
* The extender can be added to any gcc-compiled program by copying go32.exe
to be <program>.exe, where <program> is the 32-bit program. For example,
cc1plus is a gcc-compiled a.out file. cc1plus.exe is a copy of go32.exe.
When the extender runs, it looks for a file of the same name but without
extension in the same directory, and executes it if present. Otherwise,
the first parameter is the executable (ie: go32 cc1plus foo.cc).
* The extender can be merged to create one .exe file that is the extender
and the executable in one file, by using the stub.exe program:
copy /b stub.exe+myprog myprog.exe
This will only work if go32.exe is in your search path, because stub.exe
runs it. Alternatively, you can prepend go32.exe itself to an a.out file
to get a single executable (stub.exe is much smaller). Note that if
you re-compile go32 or stub, you must strip off the symbol table first.
* The extender runs programs at logical address 0. A copy of the first
1 MB of physical memory (including the AT channel) is mapped to
0xE0000000 in the program's address space. The stack grows down from
0x7FFFFFFC in the program's address space. Data usually starts at
0x00400000.
* The paging mechanism understands how SuperVGA's map their memory onto
the AT bus and automatically swaps pages as the program tries to
access them. The program sees a linear range from 0xD0000000 to
0xD0100000 that corresponds to each pixel in the 256-color modes
of SuperVGAs. To use this feature, you'll have to set the GO32
environment variable like this:
C>set go32=driver c:\djgpp\drivers\tseng4k.grd gw 640 gh 480 tw 132 th 43
These parameter pairs can be omitted or rearranged as needed. They are
the "driver" name, default graphics width and height, and default
text width and height. Libgr.a doesn't have to be recompiled, nor
do graphics programs, when a different graphics mode is selected
(the extender handles it). It is strongly recommended that the program
use the GR_default_graphics and GR_default_text modes to switch to
graphics or text. These modes use the parameters specified by the
GO32 environment variable, allowing the user to select a favorite
graphics and text mode.
* Symbols are stored in virtual memory, so you won't run out of symbol
space until both extended memory and the disk are all used up. For
large programs, you might notice a slight delay while it looks up
symbols.
* Signals are not reported to the program. However, interrupts do continue
to get serviced while in protected mode (ie: keypress, timer, etc).
CTRL-C will get you back to the debugger in debug32, and you can continue
from where you stopped. All signals (ie: exceptions) cause debugging
traps in debug32, or general faults in go32.
Copyright Information:
* Source code for the GNU utilities is copyright (c) Free Software Foundation.
For more information on the FSF copyright, see their source code or write
Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
A copy of their file "COPYING" is included in doc.arc. Some of the FSF
source code has been modified to operate properly in the MS-DOS environment.
* Source code for most of libc.a are copyright (c) Regents of the University
of California. These files include copyright information in them. The
utilities are compiled against these libraries, and thus contain software
developed by the University of California, Berkeley, and its contributors.
Some of the BSD source code has been modified to operate properly in the
MS-DOS environment.
* Any sources not falling under the copyrights of FSF or UCB (as above) are
Copyright (c) 1991 DJ Delorie, 24 Kirsten Ave, Rochester NH 03867-2954.
To contact me via E-Mail, sent to "dj@ctron.com". Cabletron Systems Inc
is in no way involved with this project; I just happen to work for them
during the day.
Terms and Conditions:
* Source code copyright FSF is distributed under the terms of the GNU
Public General License. See the file "COPYING" in doc.arc for more
information. If your program links in object modules (in libc.a) that
are compiled from GNU sources, then your entire program must be
distributed under the terms of the GNU GPL as a "derived work". These
modules are the C++ class library (including the streams classes) and
obstacks. The sources in libsrc have the copyright notices in them
for the various modules.
* Source code copyright UCB is distributed under the terms listed in the
UCB source code itself.
* Source code copyright DJ Delorie is distributed under the terms of the
GNU General Public Licence, with the following exceptions:
(source code and executables copyright DJ Delorie are referred to as
"djcode" below)
1 If the user of this software develops an application that requires
djcode to run, and that application is distributed under the terms
of the GNU General Public License (GPL), a binary executable of
djcode may be distributed with binary executables of the application,
and source files for djcode must be available with source files for
the application, under the terms of the GNU GPL.
2 If the user of this software develops an application that requires
djcode to run, and that application is NOT distributed under the terms
of the GNU General Public License (GPL), a binary executable of
djcode may be distributed with binary executables of the application,
provided a royalty of 5% of the total sale price or $5 (whichever is
more) per copy sold is paid to DJ Delorie (at the address above).
Requests for exceptions may be made to DJ Delorie, but the granting of
an exception covers only the work excepted and does not apply to
other works, even if distributed under the same conditions. Exceptions
will not be granted for any work sold for profit.
3 A person or organization who develops software that requires djcode
but does not distribute that software under the terms of the GNU GPL
relinquishes all rights to obtain or redistribute the source code
for djcode, including any rights granted by the GNU General Public
License, and may only distribute executables of djcode under the
terms of exception 2, above.
The intent of this copyright is this: If you make money by using the
programs I wrote, I get some of it. If you use your sources to
teach others how to write programs, I'll support you.
Changes to source code copyright BSD or FSF are copyright DJ Delorie, but
fall under the terms of the original copyright.
Donations may be made to any of the following:
DJ Delorie
24 Kirsten Ave
Rochester, NH 03867-2954
USA
Free Software Foundation
675 Mass Ave
Cambridge, MA 02139
USA
University of California
Berkeley, CA (sorry, I don't know their ZIP code)
USA